This section provides background information related to the present disclosure and is not necessarily prior art.
An application (referred to interchangeably in this disclosure as an “app”), such as a mobile app, may contain multiple deep states. For example, in an app that rates the quality of restaurants based on social media opinion data, the detail page for each restaurant would be considered a deep state. Deep states are reachable from within the app through a sequence of user actions that can involve navigating through multiple menu screens (or, views) as well as interactions with user interface elements. Each of these menu screens and user interface elements can be mediated by a unique view controller associated with that displayed screen.
Usually, these deep states are accessible only from within the app itself web search engines operating outside the app, for example, cannot reach the deep states within the app. This means that when a user conducts a conventional web search for restaurants and wants to explore one of the returned choices in a specialized restaurant rating app, the user would have to manually copy and paste the name of the selected search result into the search field of the restaurant rating app and command the restaurant ranking app to access its internal deep state corresponding to the selected restaurant. This represents undesirable additional interaction required of the user.
If deep states of apps could be exposed to external apps and computer processes, the user could enjoy additional functionality and convenience. For example, the user could begin a search for a suitable restaurant using an Internet-based search server and then, by selecting one of the results of that search, be automatically led to the appropriate deep linked page of a specialized restaurant ranking app.
However, implementing such functionality requires developer effort and requires deep linking expertise that the developer may not possess. When app development is limited by time, budget, or expertise, deep link functionality for some or even all of the states of an app may not be a high enough priority to get implemented.
Mobile operating systems, such as the iOS operating system from Apple Inc. and the Android operating system from Google Inc., may allow a developer to provide data to the operating system for indexing. In the iOS operating system, this may take the form of a CSSearchableItem (where the CS stands for Core Spotlight) object. The developer may implement code that bookmarks certain states of an app by providing information about those states to the operating system. In the iOS operating system, this may take the form of an NSUserActivity object (where NS stands for NeXTSTEP).
Then, users can perform a search through the operating system, where relevant data or states from the developer's app are identified. If a user selects one of those activities from an operating system interface, such as a search dialogue or a recent tasks menu, the developer's code can restore the app to the state corresponding to the bookmarked activity. A bookmarked activity on a first device may even be continued on a different device (assuming the app is also installed on the other device). Via inter-device communication, the operating system of the first device notifies the operating system of the other device what state the user was most recently interacting with.
In addition, the developer may specify that certain types of data, such as telephone numbers and names from a contact database maintained by the app, be indexed by the operating system. When a user indicates to the operating system that one of those data objects (for example, a certain contact) is of interest, the developer's code can transition to a state of the app that presents that data object for viewing or editing.
In order to take advantage of these operating system capabilities, the developer may implement code that can restore the app to a state based on indicated activity or data object. However, these activities and data objects may be known only to the operating system or to search systems maintained by a developer of the operating system. In other words, third party apps and search services may be unable to access this data and navigate directly to the states or data objects within the app.
Further, developing code to display data objects, index data objects, bookmark activities, and continue activities requires developer effort and may not be accomplished for any of an app's states much less for all of the app's states. As a result, these enhanced operating system capabilities may not be available for a variety of states of an app and may also not be accessible to third party apps and search systems.
In FIG. 1, the enhanced operating system functionality is graphically depicted. On a user device, an operating system 100 executes a first app (referred to as “App A”) 104. App A 104 includes a representative set of views, View A 108-1, View B 108-2, View C 108-3, View D 108-4, and View E 108-5 (collectively, views 108). The views 108 may be managed by one or more view controllers, which may be developed according to the model-view-controller (MVC) software architecture pattern.
As an example only, App A 104 is a restaurant information app, View A 108-1 is a home (or, default) state of App A 104 from which restaurant searches by cuisine, geography, etc. can be performed. Continuing the example, View B 108-2 is a two-dimensional app interface showing restaurant locations, View C 108-3 is a restaurant detail view, View D 108-4 is a list of restaurants by cuisine, and View E 108-5 is a list of recently-reviewed restaurants. In various implementations, including this example, a single view may be a template populated with entity-specific data. For example, View C 108-3 may have a visual layout for a restaurant specifying where a photo of the restaurant will be located, the location, size, and font face of the restaurant's name, how reviews will be summarized, etc. The visual layout view will be instantiated with data corresponding to a specific restaurant from a data store.
App A 104 selects and provides data objects to the operating system 100 for indexing. For example, App A 104 may provide the names of each of the specific cuisines encompassed by App A 104. The operating system 100 can then provide results to users who are searching by that cuisine name.
App A 104 includes an activity handler 112 that receives a continue user activity signal from the operating system 100. For example, the continue user activity signal may specify that a certain cuisine type was of interest to a user. The activity handler 112 then invokes View D 108-4 and populates View D 108-4 with results corresponding to the specified cuisine. App A 104 may be selective regarding which cuisines to provide to the operating system 100 for indexing because providing too many data objects may lead to a decrease in their average relevance. This may cause the operating system 100 to down-rank or even remove indexed objects from search results that do not appear to have high relevance.
App A 104 may, therefore, include programming that indexes a list of the most popular cuisines or cuisines whose names are more likely to be unique to cuisines. For example, while “American” may be a cuisine name, there is a high false positive rate because this term applies to many other searches than simply cuisine. However, if a user indicates interest in a cuisine, such as by reviewing the restaurant listings for a certain cuisine one or more times, App A 104 may add that cuisine name to the list of objects to index by the operating system 100.
In addition, App A 104 may indicate to the operating system 100, using an activity object, that a user is currently viewing restaurant results for a particular cuisine. This allows the operating system 100 to maintain essentially a history of activities performed by the user within App A 104. In addition, the most recent activity engaged in by the user can be shared with another device, allowing a hand-off of user interaction with that activity from one device to another. Submitting an activity object to the operating system, allowing later resumption of the activity on the same or another device, is referred to in this disclosure as bookmarking the activity.
Activity objects may be sent to the operating system 100 when the user enters View B 108-2 to view restaurant results in a map display. For example, the activity object sent to the operating system 100 may include a latitude and longitude at a center of the map. If the user adjusts the center of the map, App A 104 may provide an updated activity object to the operating system 100 indicating the new center point. App A 104 may further include in the activity object additional data such as filters. For example, the user may have restricted the displayed results to only those restaurants that are currently open. This filter may be identified in the activity object provided to the operating system 100.
The activity handler 112 may receive a continue user activity signal from the operating system 100 indicating that the user is interested in continuing a map view of restaurants at a certain center point with a certain set of filters. For example only, in the iOS operating system, this may take the form of a continueUserActivity call to the app delegate of the app. The activity handler 112 then invokes View B 108-2 with the provided parameters and presents the user with the desired map view. The continue user activity signal may have been received from another device on which the user was previously viewing that map display. As shown in FIG. 1, the activity handler 112 is programmed to invoke View B 108-2, View D 108-4, and View E 108-5, but not View A 108-1 or View C 108-3.
In the operating system 100, a search index 120 receives data objects from App A 104. The search index 120 also receives data objects from other apps and, in some implementations, from the operating system 100 itself, such as the names of frequently-accessed device settings. For example only, in the iOS operating system, the search index 120 may be referred to as Spotlight and the data objects provided to the search index 120 may take the form of CSSearchableItem objects.
The search index 120 may also receive activity metadata from an activity tracker 124. The activity tracker 124 receives activity objects, including from App A 104. An activity object may take the form of an NSUserActivity object. An activity object received by the activity tracker 124 may include metadata similar to that of a data object. The metadata can be indexed by the search index 120. The metadata may take the form of a CSSearchableItemAttributeSet object, which may be the same form used in CSSearchableItem objects.
Activities indicated as public may be shared with a cloud index maintained by the developer of the operating system 100. A cloud index interface 128 provides the public activities to the cloud index. These public activities are selectively indexed by the cloud index, allowing other users to search for and find activities generated by App A 104 even when App A 104 is not installed on their devices.
A handoff controller 132 shares the latest activity with other devices. In various implementations, the other devices have been authenticated to the handoff controller 132 to indicate that they have permission to receive the latest activities from the present device. These other devices can, therefore, allow a user to begin an activity on the device where the operating system 100 is executed and resume the activity on another device.
A search interface 136 allows a user to perform a search, such as by entering a text query. The search index 120 provides relevant search results to the search interface 136 and, upon a user selection, the user-selected result is provided to the activity tracker 124. The activity tracker 124 identifies which app corresponds to the user-selected result and sends a continue user activity signal to the relevant app. The continue user activity signal may include an indicator whether the continue user activity signal pertains to a data object or an activity object.